home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d20
/
zmh124.arc
/
ZMAILH.TXT
< prev
Wrap
Text File
|
1991-09-16
|
41KB
|
991 lines
ZmailH v 1.24
Copyright 1989,90,91 -- PROZ Software
Written by: Charles Whitlatch and Jason Steck
User Documentation
LICENSING
ZmailH and other PROZ Software products are provided "as is". No
warranty or guarantee is expressed or implied. This section serves to
absolve PROZ Software and its agents from any responsibility for damages,
liability, or loss of revenue due to the use, misuse, or inability to use
this product. In areas where such limitations on liability are not legal,
this product is not licensed for use.
ZmailH and other PROZ Software products may not be de-compiled, dis-
assembled, patched, or reverse-engineered in any way. Such actions are a
violation of PROZ Software copyright and will be prosecuted through all
available channels.
INTRODUCTION
WHAT IS ZmailH?
ZmailH is a integrated netmail/echomail processor designed for use on
Hudson-style message bases in a network environment compatible with the
FidoNet Technical Standards. At present, "Hudson-style message bases"
include those in use on such systems as QuickBBS, Remote Access, and
SuperBBS.
This manual is intended to assist you in setting up and operating
your ZmailH system.
REQUIRED EQUIPMENT
ZmailH requires the following equipment and software support to
operate:
1) PC-DOS/MS-DOS 3.0 or later.
2) At least 300k of RAM available.
3) An existing Hudson-style message base.
ZmailH OPERATION
Crash Recovery
ZMailH will occasionally write a ZmailH.CRF file in the BBS or
Zzyzx directory. This file is called the Crash Recovery File. It
tells ZMailH the position and file name of the packet file that
was being processed when the system stopped. If this file exists
on the system DO NOT DELETE it ZMailH will delete it when it has
been utilized.
ZmailH Exit Errorlevels
When ZmailH has completed its processing or stops for any
reason it will set the errorlevel to one of the following exit
codes.
Errorlevel Meaning
0 No Error / Processing performed
1 DOS Error
2 Configuration Error
3 Insufficient Disk Space
4 Net Mail Tossed/Extracted
5 Echo Mail Tossed/Extracted
255 User Abort (^C)
You may wish to trap these errorlevels with a batch file and
process them accordingly.
If a DOS error is encountered, ZmailH will create or append
to an error log in the current directory. The name of this file
is ZM_ERROR.LOG. This is an ASCII file that contains the state of
ZmailH at the time of the crash. ie. It contains all of the
command line parameters, system generated variables, and other
information. This file should prove useful for determining why
the system crashed.
INSTALLATION
ZmailH may be run from any directory. Most often the program
(ZmailH?.EXE) is placed in the BBS directory. The Control file
must be in the directory that is active when ZmailH is run or it
must be specified on the command line (See Command Line Options).
INTER-ZONE MAIL SETUP
If ZmailH is used for inter-zone mail there are several adjustments
which must be made to the system configuration. Ommm based systems, such as
Binkley, require that each zone have a separate outbound directory. Non
Ommm based systems, such as SEAdog and FrontDoor, will only require special
outbound directories if they are having ZmailH create and or archive
packets. The default outbound directory, as specified in the Zmail.ctl
file, coincides with the primary address zone. Alternate zones are handled
in directories that are named as follows: <outbound>.ZZZ where ZZZ is the
zone number in hex and outbound is your default outbound directory.
If ZmailH is used to process echo mail in more than one zone special
care must be taken to ensure that the systems that you are sending the mail
to are also addressing your system correctly.
The Key File (<Name>.KEY)
ZmailH uses a key file to ensure that only licensed copies of
the program are being used. The key file must be present in the
ZzyzxPath directory or the BBS directory if the ZzyzxPath is not
specified. The Key file is provided when you register your copy
of the program. If an appropriate key file is NOT found ZmailH will
require manual intervention to run.
The Control File (Zmail.ctl)
ZmailH uses a control file called Zmail.ctl. This file contains
information pertaining to the environment in which ZmailH is to run. It
must be in the current directory unless specified on the command line. Each
line in the Zmail.ctl file is limited to 255 characters. Any characters
that follow a semi-colon (;) are considered comments and are ignored. The
Control file provided on the ZmailH disk can be edited or a new Control
file
may be created using any ASCII editor. If you do not have any other editor
you can use the DOS EDLIN editor (See your DOS manual for more
information). Any command line option may be included in the control file.
Addressing Options
NODE
The first statement in the control file is the NODE
statement. This statement specifies what address(es)
the BBS uses. The node statement may contain more than
one address and there may be more than one node statement
in the control file. The order in which the addresses
are listed is important. The first address listed must be
the primary address. All AKA's should be listed in priority
order.
Unless explicitly stated otherwise ZmailH will assume that
the first address is in zone 1. ZmailH uses an extended
addressing scheme that includes a private network address in
the address.
The structure of the Node statement is:
NODE [<Zone>:]<Net>/<Node>[.[<PvtNet>/]<Point>].
If the node statement was NODE 1:999/102 then ZmailH would
operate with an address of zone 1, Net 999, and node 102.
NODE 999/102 would have the same effect.
If the system also had an address in zone 2 then the zone
two address would also need to be listed. For example: Node
999/102 2:333/444 would specify that the BBS has a primary
address of 1:999/102 and a secondary address of 2:333/444.
The primary address is used whenever ZmailH is exporting a
message from the system and there is no other "closer"
address. If the BBS in the above example were to send a
message to a board in zone 2 then the address ZmailH would
use as the origin address would be 2:333/444. if the message
were to go to zone 3 then ZmailH would use the 1:999/102
(primary) address.
The distinction between addresses also carries over to the
net level. Suppose a BBS had the following node statement in
the Zmail.ctl file: Node 999/102 90/3 2:333/444. If this
system were to send a message to 1:90/6 the address that
ZmailH would use for the origin address would be 1:90/3. If
the message was going to 2:90/6 then ZmailH would use the
2:333/444 address. If the message was going to 3:90/6 then
ZmailH would use the 1:999/102 address.
To specify a private net address to be used as part of a
point net attached to the system the statement would look
like: Node 999/102.102102/0. This would inform ZmailH that
the private net 102102 is also used by node 999/102. ZmailH
will also automatically forward any mail addressed to
999/102.xxx to 102102/xxx. ZmailH will automatically map all
102102/x addresses as necessary.
All echo mail that is passed into or out of the point
network will have the seen-by lines stripped down. On import
they will only contain the addresses within the private net,
on export they will only contain the addresses outside the
private net. It should be noted that all 'points' under this
node should address their echo mail to 102102/0.
MAP
The MAP command allows ZmailH to know of point net addresses
without having to specify the full address in the AREAS.BBS
file.
The structure of this statement is:
MAP [<Zone>:][<Net>]/<Node>.<PvtNet>/<Point>.
If the map statement was MAP 1:999/102.120120/0 this would
specify that 1:199/102 was the boss node for private net
120120.
Path Options
MAILPATH
The MailPath statement specifies the directory in which net
mail *.MSG files will be stored.
This control statement is required and should be of the
form: MAILPATH [<Drive>:]<Path>.
The MailPath is also used by several other programs. The
directory that it points to is one of the interface points
between these programs. Some mailers of the SEAdog type use
this directory to store messages that list files to be sent.
Other mailers like Binkley never use this directory
directly. In a Binkley environment Ommm would bundle the
messages in the MailPath directory and create packets or
archived packets. An example of the MailPath statement would
be: MAILPATH C:\MAILER\MAIL
FILESPATH
FilesPath is the path that points to the directory in which
your mailer places inbound files. This is where ZmailH will
find the packets and archived packets that need to be
processed. This is another interface directory. Both ZmailH
and your mailer must point to this directory.
The structure of the FilesPath statement is:
FILESPATH [<Drive>:]<Path>.
An example would look like: FILESPATH C:\MAILER\FILES.
OUTBOUNDPATH
The OutboundPath specifies where the final archived mail
packets should be stored. On an Ommm system this should be
the same path that is specified on the Ommm command line as
the holding path. On SEAdog type systems this may be any
directory.
The structure of this statement is:
OUTBOUNDPATH [<Drive>:]<Path>.
An example would look like: OUTBOUNDPATH C:\MAILER\OUTBOUND.
BBSPATH
The BBSPATH specifies where your BBS software is located. If
no BBS software is being used on the system then this path
should point to a directory where ZmailH files should be
stored. THIS DIRECTORY MUST BE DEFINED.
The structure of this statement is:
BBSPATH [<Drive>:]<Path>.
An example would look like: BBSPATH E:\BBS.
EXPRESSMAIL
Several off line message reading programs place packeted
mail in special directories. These systems also create
messages that have the origin address of the current system.
If these packets are moved to the netfile directory ZmailH
will detect them as forgeries (originating on the current
system) and will toss them to bad messages. To circumvent
this problem ZmailH uses an ExpressMail directory. The
expressmail directory is where the offline generated
messages will be stored.
WARNING: The ExpressMail directory is not checked for
forgeries, do not allow non-automated access to this
directory if you are concerned about forgeries.
The structure of this statement is:
EXPRESSMAIL [<Drive>:]<Path>.
An example would look like: EXPRESSMAIL C:\XRS\
DUPPATH
The DupPath is an optional statement that specifies where
duplicate *.MSG messages should be placed. If the statement
is omitted no *.MSG files will be created and the processing
of packets will be much faster.
The structure of the DupPath statement is:
DUPPATH [<Drive>:]<Path>.
An example would be: DUPPATH E:\MAIL\DUPS.
BADMSGS
The BadMsgs is an optional statement that specifies in what
directory any bad messages should be stored. This command
has the same limitations, restrictions as the DupPath
statement. Bad messages are created when using echo security
or when mail forwarding and echo forwarding are not enabled.
The structure of this statement is:
BADMSGS [<Drive>:]<Path>.
An example is: BADMSGS E:\MAIL\BAD
ARCHIVEPATH
The ArchivePath is an optional statement that specifies
where temporary outbound packets should be created and
updated. If not specified then the outbound path is used.
The ArchivePath statement allows the sysop to specify a
drive with extra free space to be used to create the
outbound packets. Some speed increase may be seen if the
ArchivePath is on a different drive than the Outbound path.
The structure of this command is:
ARCHIVEPATH [<Drive>:]<Path>.
An example is: ARCHIVEPATH F:\OUT
WARNING: Do NOT use a RAM disk for the Archive Path. Due to
the nature of the ZmailH disk space detection algorithm it is
possible to have incomplete packets in the ArchivePath
between runs. Should the power fail during one of these
periods the incomplete packets and all messages in them
would be lost.
UNARCPATH
The UnArcPath is an optional statement that specifies where
the inbound mail packets are to be unpacked. If it is not
specified then the FilesPath is used. The ArchivePath
warning also applies to the UnArcPath statement.
The structure of the UnArchive Path is:
UNARCHIVEPATH [<Drive>:]<Path>.
An example is: UNARCHIVEPATH F:\IN
ZMAILPATH
The ZMAILPATH is an optional statement that specifies where
the ZMailH ancillary files will be found. ZmailH will look in
this directory for the signature and Key files.
The structure of this statement is:
ZMAILPATH [<Drive>:]<Path>.
An example would look like: ZMAILPATH E:\BBS\ZMAIL
SWAPPATH
The SWAPPATH is an optional statement that specifies the
directory (preferably a RAMDisk) where ZmailH will write its
swap file. The swap file is a file which ZmailH uses to
store its current status in while executing external programs
such as archivers and unarchivers. Storing this file allows
ZmailH to temporarily remove itself from memory to provide
greater RAM availability for external programs. If available,
EMS (Expanded Memory) which conforms to the LIM/EMS 3.2 standard
or higher will automatically be used instead of the SWAPPATH.
Mail Compression Options
ARCCOMMAND
The ArcCommand is used to archive the mail. If ZmailH never
archives the outbound mail then this line does not need to
be specified. The archiving function must be specified on
the command line (See Command Line Options).
The structure of this command is:
ARCCOMMAND <Drive>:<Path><Archive Program> <parameters>.
A full drive and path to the archive program must be
specified as well as the extension of the archiving program.
The sysop must also specify the location for the archive and
file names on the archiving programs command line. To do
this the sysop places a %A where the archive name should be
and a %F where the file name to extract should be.
To use the "standard" ARCA command the control file
statement would be: ARCCOMMAND C:\UTIL\ARCA.COM %A %F /D
UNARCCOMMAND
The UnArcCommand is the command that is used to unarchive
inbound archived packets. If ZmailH never unarchives mail
packets then you do not need to use this line. The
unarchiving function must be specified on the command line
(See Command Line Options).
In order to allow the sysop to use any unpacking program the
structure of this statement is somewhat complicated:
UNARCCOMMAND <Drive>:<Path><Unarchive Program> <Parameters>.
This command has the same structure and limitations as the
ArcCommand.
For example to use the "standard" ARC program in The C:\UTIL
directory then the line would read: UNARCCOMMAND
C:\UTIL\ARC.COM -E %A. To use ZOO as the unpacker the line
would look like: UNARCCOMMAND C:\UTIL\ZOO.EXE -E %A. If the
sysop has a program called PickARCE.EXE that will determine
what unpacker to use then the command line might look like:
UNARCCOMMAND C:\UTIL\PICKARCE.EXE %A. If the sysop had a
batch file to call the proper unpacking program then the
command line would look like: UNARCCOMMAND C:\COMMAND.COM /C
UNPACK.BAT %A
WARNING: Do not use a batch file unless you are certain that
you will never run short of disk space, and you are certain
that the batch file works. ZmailH can not determine
Errorlevels generated by programs run inside batch files.
ZmailH does not have internal facilities to determine what
type of packer was used. It is the responsibility of the
sysop to ensure that the proper unpacker is being called.
Note: As of this writing ARC() 5.2 is the FidoNet standard
for archived mail.
System Options
OMMM
The OMMM command tells ZmailH that it is operating in an OMMM
environment. If you are running SEAdog, Front Door, or any
other mailer that does not use Ommm than you MUST REMOVE
this line.
The format of this statement is:
OMMM.
FDFIX
The FDFIX command tells ZMailH that your system uses a FrontDoor
message editor. This command is MANDATORY on all systems which
use the FrontDoor editor in order to work around a bug in the way
FrontDoor's editor treats message replies.
PASSWORDFILE
The PasswordFile statement is an optional statement that is
used to point to a password file to be used with packet
security (see command line options). Passwords may be up to
8 characters in length and are not case sensitive.
The structure of the statement is:
PASSWORDFILE [<Drive>:]\<Path>\<FileName>[.<Extension>]
The internal structure of the password file is:
<Address> <Password>
<Address> <Password>
An example of the file is:
1:999/123 FRED
2:123/456 mark
1:102/214.5 JoesPwd
NOSEENBY
The NoSeenBy statement is an optional statement that
inhibits the importation of the seen-by lines. Seen-bys are
still processed and included on messages that are passed
through the system.
This statement has the structure:
NOSEENBY
NOPATH
The NoPath statement is an optional statement that inhibits
the importation of the path lines. Paths are still processed
and included on messages that are passed through the system.
This statement has the structure:
NOPATH
LOGLEVEL
When executing ZmailH writes a log in the current directory.
The loglevel option allows the sysop to set the level of log
reporting. Each level will include the information from
lower log levels as well as the current level. The valid
levels are from 0 to 6 with the default being 5. The log
level settings correspond to the following:
Level Log Entries
0 Start and Stop times
1 Dos Errors
2 Configuration Errors
3 Insufficient Disk Space
4 Internally Compensated Errors
5 Information
6 Detailed processing information
An example of this command is:
LOGLEVEL 3.
This log level would produce a log that contained only
references to Dos Errors, Configuration Errors, or
Insufficient Disk Space errors.
RETAIN
In order to maintain the echo mail "signatures" ZmailH allows
the sysop to specify how long to keep each signature. Retain
is an optional command. If it is not used then the default
retention period is 30 days. When an echo mail message is
received and processed its signature is stored in a file
along with the date. If the signature is not seen again for
the duration of the retention period then the signature is
removed from the file during the clean operation (See Clean
Command Line Option).
The retain command has two formats:
RETAIN <DAYS>
and
RETAIN <AREA TAG> <DAYS>.
The first example changes the default retention from 30 to
<Days>.
For example the statement RETAIN 15 would change the default
retention period from 30 to 15 days.
The second example is used to change the retention period
for a single conference. For example the statement RETAIN
SYSOP 25 would change the retention period of signatures in
the "Sysop" echo from the default to 25 days.
Each retain command must be on a separate line.
Locking Options
RALOCK, QUICKLOCK, SBBSLOCK
The locking statements are provided for those systems which may
be running ZmailH in a multi-line environment using QuickBBS
2.75 (Gamma-2) or higher, Remote Access 1.00 or higher, or
SuperBBS 1.12 (Beta-12) or higher.
Use of a locking statement will cause ZmailH to attempt to obtain
a "lock" on the message base before importing a message into it.
This locking prevents message base corruption due to conflicts
in a multi-line environment.
When attempting to obtain a lock, ZmailH will check to ensure that
no other application (such as the BBS itself) presently has a
lock established on the message base. If a lock cannot be
obtained, ZmailH will re-try for five seconds. If the lock cannot
be obtained after that time, ZmailH will save its current status
(for continuation on the next run) and abort to prevent corruption
of the message base.
The locking statements are optional. Systems not running in a
multi-line environment should not utilize a locking statement
in the Zmail.ctl file. Systems which DO have locking statements
must have share.exe loaded or else locking will fail and ZmailH
will abort.
LIST OF CONFERENCES (AREAS.BBS)
In addition to the above files an AREAS.BBS file is also required.
The sysop must create the AREAS.BBS file based on the names of the
conferences that the system is carrying. The AREAS.BBS file must be in the
current directory when ZMailH is run unless specified on the command line
(See Command Line Options).
The first line of the AREAS.BBS file is a considered a comment line
and is not used.
The structure of the remaining lines is:
<Board #> <Tag> [<Zone>:]<Net>/<Node> [[[<Zone>:]<Net>/]<Node>]
The <Board #> is a the number of the board specified in the
configuration program.
If the echo conference is to be passed through to another system and
you do not wish to keep a copy on your system then the structure is:
P <Tag> [<Zone>:]<Net>/<Node> [[[<Zone>:]<Net>/]<Node>].
Unlike other echo mail processors ZmailH does not create *.MSG format
messages for pass through areas.
Each area that you receive and/or forward must be listed in the
AREAS.BBS file. There may be more than one line for each area. However
each line must be a valid AREAS.BBS line.
The zone numbers are optional as long as the systems that you are
passing the echo to are in the same zone as your primary address. Once a
zone has been specified it does not need to be specified again. For
example:
1 SYSOP 1:99/864 1:99/369 2:333/44 2:543/21
is the same as
1 SYSOP 1:99/864 99/369 2:333/44 543/21
Like the zone numbers net numbers only need to be listed once. This
means that the above line could be written as: 1 SYSOP 1:99/864 369
2:333/44 543/21.
The extended addresses, as explained in the node statement, are also
valid. For example:
1 SYSOP 1:99/864.864864/2 369 2:333/444 543/21
Would cause the SYSOP echo to be forwarded to 864864/2, which is understood
to be a point under 99/864.
ZmailH also provides a method to override the command line options
that affect echo mail packeting. If an asterisk '*' is placed before an
address in the areas.bbs file then all messages forwarded to that address
in the current conference will be written to the net mail area as *.MSG
files. This is used primarily to interface with UUNET and other 'external'
networks.
For example:
UUCP_AREA 99/864 *32/100
would cause all messages to 32/100 to be tossed as *.MSG files in the net
mail directory while messages to 99/864 will be processed according to the
command line options.
ZmailH will, by default, create "normal" packets, these packets are
neither crash nor hold. When looking for file attaches ZmailH will look for
attaches that have the same flavor as the packets that were created. If
your mail bundling program changes the flavor of the attaches then ZmailH
will not be able to add to the archive. For this reason flavor characters
may proceed the address and follow the asterisk if one exists. The valid
flavor characters are: "C" for Crash, "H" for Hold, and "N" for normal.
WARNING: If you find that your system is creating many small packets for a
system verify that the flavor is not being changed and that you have the
correct flavor letters in the AREAS.BBS file.
The complete address entry for the AREAS.BBS file is:
[*][<Flavor>][<Zone>:][<Net>/]<Node>[.[<Pvt Net>/]<Point>]
COMMAND LINE OPTIONS
ZmailH is typically run from a batch file. The command line
options listed below control how ZmailH will interact with the
system on any given run. Any command line option can be listed in
the control file. Command line options override control file
statements. Command line options can be divided into five basic
categories: general, file, packet, echo mail, and net mail.
General Commands
C (Clean)
Instructs ZmailH to clean the message signature files. This
command also causes ZmailH to delete any signature files for
areas that are no longer carried on the system. it is
recommended that signature file cleaning be performed once
per day.
S (Scan)
Instructs ZmailH to scan the bad message area. ZmailH will
then import or forward any messages that were listed as bad
messages but are now valid. Such a condition may occur when
a hub forgets to turn on an echo for a node.
T[<FileName>[.<Ext>]] (Traffic)
Instructs ZmailH to generate an echo mail traffic report. The
report will contain the average volume of echo mail traffic
for all of the echo conferences that are carried on or pass
through the system as well as the total number of signatures
that are in the file. The report is useful for determining
what echo areas are dead, if a conference has not been
turned on by your echo mail hub, and how many messages to
retain in each of the areas. The report will be appended to
the file <FileName> if it exists. If <FileName> does not
exist it will be created. If <FileName> is not specified the
report will be written to the screen.
QB (Quiet Bell)
Instructs ZmailH to Quiet the Bell. This inhibits any beeping
that would have otherwise occurred.
QS<n> (Quiet Screen)
Instructs ZmailH to Quiet screen writes. The <n> is the
equivalent of the log level. The default is 6.
File Commands
FA<FileName>[.<Ext>]
Instructs ZmailH to use <FileName>[.<Ext>] instead of the
standard AREAS.BBS file.
FC<FileName>[.<Ext>]
Instructs ZmailH to use <FileName>[.<Ext>] instead of the
standard Zmail.ctl file.
FL<FileName>[.<Ext>]
Instructs ZmailH to generate a list of all of the echo areas
that had messages tossed into them. The list will be
appended to <FileName>[.<Ext>] if it exists. If
<FileName>[.<Ext>] does not exist it will be created. If
<FileName>[.<Ext>] is not specified the ZmailH will display
the list on the screen.
Packet Commands
PU (Packet Unarc)
Instructs ZmailH to unarchive any archived mail it finds in
the directory specified by the FilesPath control file
statement. If this option is not specified any archived mail
will not be processed.
PI (Packet Import)
Instructs ZmailH to process any unarchived mail packets it
finds in the directories specified by the FilesPath and
UnArchivePath control file statements. If this command is
not specified then any mail packets that exist in the
FilesPath and UnArchivePath directories will not be
processed.
PF (Packet Forward)
Instructs ZmailH not to unpack any unarchived mail packets
that are destined for another system. With the PF option
those packets are simply forwarded. This option only works
with packets that were created by another ZmailH system and
it supersedes the PS option listed below.
PS (Packet Security)
Instructs ZmailH not to unpack any unarchived mail packets
that are not destined for the BBS. ZmailH will rename these
packets to BADPKT.*. In addition a password may be added to
the packet. Packet passwords are stored in the file
specified by the PasswordFile control file statement. At
this time ZmailH will only check for passwords on packets
from other ZmailH systems.
PA (Packet Archive)
Instructs ZmailH to archive ALL outbound packets created
during this run.
WARNING: On Ommm systems, if net mail is packeted and
archived then no routing may occur.
PC (Packet Crash)
Instructs ZmailH to mark all generated packets as crash mail.
PH (Packet Hold)
Instructs ZmailH to mark all generated packets as hold.
Echo Mail Commands
EI (Echo Import)
Instructs ZmailH to import all inbound echo mail messages. If
this option is not specified then all echo mail messages
will be tossed, as *.MSG files, into the directory pointed
to by the MailPath control file statement. Imported echo
areas must appear in the AREAS.BBS file (or the file
specified by the FA<FileName>[.<Ext>] option above.). If the
echo name is not located in the file then the message will
be tossed, as a *.MSG file, into the directory pointed to by
the BadMsgs control file statement. If the BadMsgs directory
is not defined then the message is deleted.
ES (Echo Security)
Instructs ZmailH to verify that the system that forwarded the
echo mail message to the BBS is listed in the AREAS.BBS file
(or the file specified by the FA<FileName>[.<Ext>] option
above). If the message fails the security check then it is
tossed, as an *.MSG file, into the directory pointed to by
the BadMsgs control file statement. If the BadMsgs directory
is not defined then the message is deleted. This option has
no effect if the EI option is not activated.
EF (Echo Forward)
Instructs ZmailH to forward any echo mail messages that were
not generated on the BBS. This only occurs when one system
is using the current system to forward mail to a third
system. For this option to work the area must be listed in
the AREAS.BBS or FA<FileName>[.<Ext>] option file, otherwise
the message will be tossed as a bad message by the EI
option. If this option is not enabled then the messages are
tossed, as *.MSG files, to the directory specified by the
BadMsgs control file statement. If the BadMsgs directory is
not defined then the messages are deleted. This option has
no effect if the EI option is not activated.
EE (Echo Export)
Instructs ZmailH to scan the BBS echo messages for any new
outbound echo mail. The messages are extracted and forwarded
to the other nodes receiving the echo as specified in the
AREAS.BBS file (or the file specified by the
FA<FileName>[.<Ext>] command line option above).
NOTE: Due to ZmailH's one pass algorithm this command should
only be run after echo mail is entered on the system.
EP (Echo Mail Packet)
Instructs ZmailH to create packet files for all outbound echo
mail. If this option is NOT used then *.MSG files are
created in the directory specified by the MailPath control
file statement.
Net Mail Commands
NI (Net mail Import)
Instructs ZmailH to import all inbound net mail messages. If
this option is not specified then all net mail messages will
be tossed, as *.MSG files, into the directory pointed to by
the MailPath control file statement.
NS (Net mail Security)
Instructs ZmailH not to scan the directory pointed to by the
MailPath Control file statement. This prevents other systems
from dropping unauthorized or forged echo mail messages onto
your system so that it will forward them into the network.
NF (Net mail Forward)
Instructs ZmailH to forward any net mail messages that were
not generated on the BBS. Regardless of the flavor that the
message had when it arrived on the system the flavor or the
forwarded message will be normal to allow for message
routing. If files are attached to a message that is
forwarded through the system the file is placed on hold and
the message is sent along with an appended line informing
the recipient that the file is on hold. This command must be
used on host and hub systems that may forward mail for other
systems. If this option is not enabled then the messages are
tossed, as *.MSG files, to the directory specified by the
BadMsgs control file statement. If the BadMsgs directory is
not defined then the messages are deleted.
NE (Net mail Export)
Instructs ZmailH to scan the BBS net mail messages for any
new outbound net mail. The messages are extracted and sent
to the addressed node.
NP (Net mail Packet)
Instructs ZmailH to create packet files for all outbound net
mail provided the messages are not marked crash or hold and
do not have files attached. If this option is NOT used then
*.MSG files are created in the directory specified by the
MailPath control file statement.
Note: On non Ommm systems net mail is not usually packeted.
Also, packeted net mail can not be routed.
COMMAND LINE EXAMPLES
Because ZmailH is so configurable and because it handles three
distinct jobs; mail importing, net mail exporting, and echomail exporting,
it is beyond the scope of this document to give examples of all possible
configuration options. However, included here are some of the more common
command line options.
Import Command Line
ZMailH PI PA PU EI EP EF NI NF
This command line is probably the most common and should
work for 80% of the systems. It causes ZmailH to unarchive,
and import any inbound packets, import to the database any
echo or net mail messages, create packets for any outgoing
echo mail messages and then archive those packets. It should
be noted that because the packets are archived they can not
be routed in an Ommm environment. Any net mail that is not
destined for the system is placed in the net mail directory
and is not packeted.
Export Command Line
ZMailH EE EP PA NS
This command is probably the most common export command line.
*.MSG messages in the net mail area will not be scanned and
packeted with the echo mail. This is useful if net mail was
previously extracted, an external bundler has not been run,
and the sysop does not want the net mail to be bundled with
the echo mail. Removing the NS entry and replacing it with an
NP entry would cause netmail to be packeted and archived.
WARNING: If net mail messages are packeted and archived they
can not be routed automatically. The routing program will
not be able to reroute them. This is of particular
importance when net mail and echo mail traffic is generated
at the same time. It is usually better to extract echo mail
and bundle it prior to extracting the net mail.
CUSTOMER SUPPORT
Support Echo
The ZMAIL support echo is currently available on many network's
echomail "backbone". Networks which are known to carry the ZMAIL echomail
conference include FidoNet, MetroNet, NETWork, and AlterNet. This echo is
intended as the direct line to PROZ Software for questions, answers,
requests and comments regarding ZmailH.
Obtaining New Keys
Any registered ZmailH user may receive a new key should the old key
be destroyed (due to a disk error, for example) or should the user's
address change. To receive a new key, contact the dealer where you
originally purchased your key and inform him/her of your need for a new key
and, if applicable, your new address. Please include information to assist
the dealer in finding your original purchase record such as your old
address or, if necessary, a copy of the original canceled check.
Netmail Support
Netmail support for questions regarding ZmailH can be obtained from:
Jason Steck
FidoNet 1:104/424
MetroNet 200:5000/400
EggNet 99:910/952
Network 8:7703/10
COMPRESS UTILITY
The Compress utility (zcmprs?.exe) is used to physically
shrink the size of the signature file. The file cleaning process
will free up space within the file to be used again by the system
however it does not physically shrink the file size. Compress
should not be run during daily maintenance but after an echo has
been removed from the system. The reason Compress should not be
run every day is that if all of the internal space is removed
from the signature file then ZmailH will spend more time expanding
the file, thus causing the system to run slower.
Compress must be run in the directory in which the
ZM_Dups.Sig file exists. It has one optional command line
parameter: /B. The /B will instruct Compress that you want to
delete the backups after compression.
Compress requires that the free space available on the disk
be at least as much as the size of the signature file. Compress
will create a new signature file from the old one and, when
finished, rename the old signature file to ZM_Dups.BAK unless the
/B option is specified
Compress will return one of four errorlevels when it exits.
Errorlevel Error
0 No Error -- processed normally
1 No signature file found
2 Unable to create temporary file
3 Unable to close new file -- Disk Full?
RECOMMENDED UTILITIES
The following utilities are suggested as recommended additions
to a ZmailH implementation:
REC (Remote Area Control)
REC is an automatic areas.bbs maintenance and update utility
like Areafix. REC supports the special areas.bbs flavor codes
included in ZmailH areas.bbs files.
Author: Dan Fitch (1:104/438@FidoNet)
Latest Release: 1.20
PolyXArc
PolyXArc is a multiple-format archive extractor program. This
utility could be used as the UNARCCOMMAND in Zmail.ctl to easily
extract many different formats of incoming mail archives.
Author: Jeffrey Nonken (1:273/715@FidoNet)
Latest Release: 2.10a
TwoPk
TwoPk allows multiple-format archiving on outbound packets. This
utility could be used as the ARCCOMMAND in Zmail.ctl to easily
allow multiple archiver use on a system-by-system basis for
outbound mail files. WARNING: DO NOT USE TWOUPK UTILITY FOR
EXTRACTION WITH ZmailH 1.20!
Author: Charlie Teufert (1:269/203@FidoNet)
Latest Release: 1.14
ZMailCfg
ZMailCfg is a program designed to assist the ZmailH sysop with
setup and configuration of Zmail.ctl file options.
Author: Joe Lindstrom (1:134/55@FidoNet)
Latest Release: 1.20